\begin{verbatim}
 \section*{Software Toolset}
 \begin{itemize*}
-\item Programming languages: Java, JavaScript, PHP, HTML, XML, CSS
+\item Programming languages: Java, JavaScript, PHP, HTML, XML, CSS, Clojure, Ruby
 \item Data Sources: MySQL
 \item Version Control: Google Code/Mercurial
 \item Bug tracking: Google Code
-\item Framework/Software: Android API, Native Java API, Google Map API, LAMP
+\item Framework/Software: Android API, Native Java API, Google Map API, Ant, Hudson
 \end{itemize*}
 
 We chose the Android platform because the Android API has many built-in features
@@ -28,11 +28,13 @@
 
 For the client-side application, we decided to go with a browser-agnostic web
 application because it would be cross-platform compatible. Clients can access
-the web application through their mobile devices or desktop computers. The web
+the web application through their laptop or desktop computers. The web
 application will be implemented by using a combination of JavaScript, PHP, HTML,
 and CSS because JavaScript, HTML, and CSS are languages that are widely
-supported by most internet browsers while PHP is supported by many servers,
-including in the LAMP setup, to handle server-side inquires.
+supported by most internet browsers while PHP is supported by many servers. We
+will be using the JVM to spawn the server and keep it running We will use Clojure
+as the main language behind the server as well as using Ruby to help with the
+building of a release.
 
 MySQL database will be the back-end to the system for storing information. We
 choose MySQL because it is free, open-source, and most importantly, has a Java
@@ -41,7 +43,10 @@
 Lastly, we use Google Code for version control and bug tracking because it is
 free and all of our data will be safely stored on Google's server which allows
 team members to have easier decentralized access to our code without having to
-worry about data lost.
+worry about data lost. We will also use Ant to facilitate the building of our
+overall release. We will also use Hudson to maintain an automated build so our
+tests will be ran every build and we will be alerted if anything pushed to our
+repository breaks the building process.
 
 \section*{Group Dynamics}
 \begin{itemize*}
@@ -201,22 +206,20 @@
   \end{itemize*}
 
 \section*{Risk}
-One major risk associated with this project is that part of our final product is
-dependent on a PhD student not on our team nor under our influence. As such, if
-the individual does not deliver, our product will fail to work correctly as
-specified in the requirements. Another major risk is that we are working with
-unfamiliar hardware. Not many of us have worked with Android devices or have
+One major risk associated with this project is that the amount of time we have
+remaining to finish the project is very little. Combine this with the fact that,
+we have other classes, it is a real risk. Another major risk is that we are working 
+with unfamiliar hardware. Not many of us have worked with Android devices or have
 done with interactions between a server and a client device so this will be a
 challenge. Another risk is that the specifications are not flexible so we are
 possibly stuck with being required to complete a difficult problem which could
 otherwise be easy if the specifications were bent a bit.
 
-The risk that worries us the most is the PhD student's contribution to the
-project. This risk worries us the most because we have no control or insight
-into any of the work done by the PhD student. As a result, it could be possible
-that the PhD student never gets us a working route finding algorithm. Overall
-all these problems are the most serious risks associated with this project. If
-we can't get our PhD student's algorithm, our project doesn't work. We are
+The risk that worries us the most is the time we have to finish the project. We
+know that we can't increase the amount of time and as the quarter heads toward the
+end, many of us are feeling the pressure of not only this class, but others. Overall
+all the aforementioned problems are the most serious risks associated with this project. 
+If we don't have the time to finish our project, we don't have the time. We are
 working with new hardware that we need to learn and therefore not necessarily
 may not able to master it. We also have the problem of not being able to change
 how an area of the project is done as it is generally fixed in stone.
\end{verbatim}